[Previous] [Next] [Index]
[Thread]
Re: Applet security (was Re: ActiveX security hole reported).
1) The class file is extended to include the object signature block. No other
enveloping mechanis is used. See http://eco.eit.com/solidoak/
2) Actually, it is based on RFC-1847 and nothing prevents S/MIME being used to
provide the MIME security. If you are interested, please view:
http://eco.eit.com/mapplet/
3) You are right. Using SSL requires trust in the server AND that no one has
managed to spoof the server using man in the middle kind of an attack.
Ali
At 05:04 PM 8/28/96 -0700, Paul Rarey wrote:
>On Aug 27, 15:05, Alireza Bahreman wrote:
>> Subject: Re: Applet security (was Re: ActiveX security hole reported).
>>
>>EIT has developed two approaches for Applet Security (no fine grain auth):
>>1) Use RSA to sign applets and verify at the browser side before allowing
>>access
>
>What enveloping strategy would be used to carry the signature and object?
>
>>2) Wrap Applets inside MOSS messages (secure MIME)
>
>This I like. The S/MIME folks will want it a different way though (I'm not
keen
>on S/MIME). The down side is - I've heard a bit about MOSS being to "big" to
>easily implement (IMC Resolving Security work).
>
>How about something along the lines of rfc1847?
>
>>we have also thought of another alternative which we have not developed or
>>tested. That is use of SSL to download applets (as in https://blaw.blaw...).
>
>I don't see how SSL allows the execution engine (Java or ActiveX) to
>authenticate the object(s), only to authenticate the server it came from.
Good,
>but seems complete.
>
>[ snip ]
>
>Cheers!
>[ psr ]
>
>
>